Preserve the .debug_gdb_scripts section #143679

sebastianpoeplau · 2025-07-09T11:40:46Z

Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to llvm.used. This
eliminates the need for a volatile load in the main shim; since the LLVM
codegen backend is the only implementer of the corresponding trait
function, remove it entirely.

Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that omit_gdb_pretty_printer_section keeps
working with dylib dependencies.

r? @bjorn3

rustbot · 2025-07-09T11:40:53Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

compiler/rustc_codegen_llvm/src/debuginfo/gdb.rs

compiler/rustc_codegen_gcc/src/debuginfo.rs

tests/codegen/gdb_debug_script_load.rs

bjorn3 · 2025-07-09T13:27:04Z

@bors r+

bors · 2025-07-09T13:27:08Z

📌 Commit d54c3ea has been approved by bjorn3

It is now in the queue for this repository.

…b-scripts-section, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? `@bjorn3`

…b-scripts-section, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? ``@bjorn3``

Rollup of 8 pull requests Successful merges: - #140136 (Add an aarch64-msvc build running on ARM64 Windows) - #143642 (stdarch subtree update) - #143679 (Preserve the .debug_gdb_scripts section) - #143707 (Fix `--skip-std-check-if-no-download-rustc`) - #143722 (Make some "safe" llvm ops actually sound) - #143728 (Resolve refactor: extraction of `finalize_module_binding` and `single_import_can_define_name`) - #143742 (Rework borrowing suggestions to use `Expr` instead of just `Span`) - #143744 (Properly track the depth when expanding free alias types) r? `@ghost` `@rustbot` modify labels: rollup

tgross35 · 2025-07-11T00:19:45Z

Looks like some GDB tests failed #143755 (comment)
@bors r-
@bors2 try jobs=dist-i586-gnu-i586-i686-musl

…ection, r=<try> Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? `@bjorn3` try-job: dist-i586-gnu-i586-i686-musl

rust-bors · 2025-07-11T00:19:50Z

⌛ Trying commit d54c3ea with merge f7ba1a6…

To cancel the try build, run the command @bors2 try cancel.

rust-bors · 2025-07-11T01:30:37Z

💔 Test failed

CI ❌

sebastianpoeplau · 2025-07-11T08:00:37Z

Looks like some GDB tests failed #143755 (comment)

Interesting, I'm going to have a look. The test passes on my x86_64-unknown-linux-gnu; I'll try to find what's different in the CI job. The name dist-i586-gnu-i586-i686-musl suggests that it's a 32-bit build - where can I find out more? Is there a way to run the same setup locally?

tgross35 · 2025-07-11T08:36:12Z

You might be able to get away with passing --target ... to ./x since these tests should still be able to run on your host. It looks like it fails testing i686-unknown-linux-musl.

If that doesn't repro it for some reason you can replicate the CI setup pretty much exactly by running the docker tests https://rustc-dev-guide.rust-lang.org/tests/docker.html, with the downside that this takes about as long as CI does.

sebastianpoeplau · 2025-07-11T10:29:20Z

Hmm, the full log of the CI job led me to believe that it's i586-unknown-linux-gnu, but locally the test passes for that target (running ./x.py test tests/debuginfo/embedded-visualizer.rs --target i586-unknown-linux-gnu). Will try with the musl target 👍

I noticed though that my GDB is version 15, whereas the test log shows GDB 12; maybe that's the reason for the discrepancy. In general, the .debug_gdb_scripts section looks correct to me...

tgross35 · 2025-07-11T10:45:44Z

You're right, it's i586. I must have been reading the wrong line.

##[group]Testing stage2 compiletest suite=debuginfo mode=debuginfo (x86_64-unknown-linux-gnu -> i586-unknown-linux-gnu)

I assume there probably isn't any reason we need to keep a very old gdb version if that makes a difference

…ection, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies. r? `@bjorn3`

bors · 2025-07-26T20:37:57Z

⌛ Testing commit 2133b4f with merge 09737a6...

bors · 2025-07-26T21:52:20Z

💔 Test failed - checks-actions

sebastianpoeplau · 2025-07-28T11:55:21Z

Some more tests needed to be ignored on i586-unknown-linux-gnu due to the outdated linker. Sorry...

bjorn3 · 2025-07-28T12:00:37Z

@bors r+

bors · 2025-07-28T12:00:39Z

📌 Commit aec2912 has been approved by bjorn3

It is now in the queue for this repository.

sebastianpoeplau · 2025-07-28T12:03:03Z

The only case I can imagine this reducing debugability is when you use a rust dylib as plugin loaded with dlopen and this rust dylib uses #![debugger_visualizer(gdb_script_file = "...")].

Is this a common case? If so, or if we want to fix it nonetheless, then maybe the .debug_gdb_scripts sections could be made per-crate once the omit_gdb_pretty_printer_section tests don't cause problems anymore. That is, instead of collecting pretty printers transitively during compilation of executables/staticlibs/cdylibs, the compiler could collect pretty printers for the current crate only, relying on the .debug_gdb_scripts sections in Rust dylibs for dependencies 🤔

…ection, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies. r? `@bjorn3`

bors · 2025-07-28T15:17:12Z

⌛ Testing commit aec2912 with merge 3b8ad43...

bors · 2025-07-28T16:37:08Z

💔 Test failed - checks-actions

sebastianpoeplau · 2025-07-29T08:46:19Z

The x86_64-unknown-linux-musl CI image has the same problem as i586-unknown-linux-gnu: the linker is too old.

$ x86_64-linux-musl-ld --version
GNU ld (GNU Binutils) 2.33.1
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Looking at musl-toolchain.sh it seems that we use https://github.com/richfelker/musl-cross-make to set up the musl toolchain. Our version of that repository is from April 2022; should I try using a more recent commit? Or disable the tests for x86_64-unknown-linux-musl as well? Or give up? 😅

bors · 2025-07-30T13:10:16Z

☔ The latest upstream changes (presumably #144673) made this pull request unmergeable. Please resolve the merge conflicts.

bjorn3 · 2025-07-31T15:02:36Z

That can be fixed later by replacing #![omit_gdb_pretty_printer_section] usage in the test suite with telling gdb to ignore .debug_gdb_scripts I think.

Opened #144738 for this.

bjorn3 · 2025-07-31T15:05:57Z

Our version of that repository is from April 2022; should I try using a more recent commit?

There is an open PR for updating musl, but it isn't something that can just be done due to some ABI breakage.

Maybe you could retain the volatile load inside main in addition to marking the global variable as used? For older toolchains the volatile load will be used for retaining the section in executables that use libstd, while for newer toolchains the used flag would be used for this instead for retaining the section in all executables.

sebastianpoeplau · 2025-08-01T07:23:57Z

We would lose the advantage of being able to remove that code, but I guess it's our best option to stay compatible with old linkers 🤔 Will do.

Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to "llvm.used". The volatile load in the main shim is retained because "llvm.used", which translates to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker; emitting the volatile load ensures compatibility with older linkers, at least when libstd is used. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies.

Instead of collecting pretty printers transitively when building executables/staticlibs/cdylibs, let the debugger find each crate's pretty printers via its .debug_gdb_scripts section. This covers the case where libraries defining custom pretty printers are loaded dynamically.

sebastianpoeplau · 2025-08-01T11:27:14Z

I've changed the code to add the global to llvm.used in addition to the volatile load. The second commit drops the transitive collection of pretty printers and therefore depends on your fix for omit_gdb_pretty_printer_section in #144738.

rustbot assigned bjorn3 Jul 9, 2025

bjorn3 reviewed Jul 9, 2025

View reviewed changes

compiler/rustc_codegen_llvm/src/debuginfo/gdb.rs Outdated Show resolved Hide resolved

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch 2 times, most recently from 97ac05e to 07de96b Compare July 9, 2025 12:16

bjorn3 reviewed Jul 9, 2025

View reviewed changes

compiler/rustc_codegen_gcc/src/debuginfo.rs Show resolved Hide resolved

bjorn3 reviewed Jul 9, 2025

View reviewed changes

tests/codegen/gdb_debug_script_load.rs Outdated Show resolved Hide resolved

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from 07de96b to d54c3ea Compare July 9, 2025 13:20

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 9, 2025

tgross35 mentioned this pull request Jul 10, 2025

Rollup of 8 pull requests #143753

Closed

tgross35 mentioned this pull request Jul 10, 2025

Rollup of 8 pull requests #143755

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 11, 2025

bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jul 26, 2025

This comment has been minimized.

Sign in to view

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 26, 2025

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from 2133b4f to aec2912 Compare July 28, 2025 11:53

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 28, 2025

This comment has been minimized.

Sign in to view

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 28, 2025

bjorn3 mentioned this pull request Jul 31, 2025

Remove the omit_gdb_pretty_printer_section attribute #144738

Open

sebastianpoeplau added 2 commits August 1, 2025 12:58

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from aec2912 to 13f9889 Compare August 1, 2025 11:25

Preserve the .debug_gdb_scripts section #143679

Are you sure you want to change the base?

Preserve the .debug_gdb_scripts section #143679

Conversation

sebastianpoeplau commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjorn3 commented Jul 9, 2025

Uh oh!

bors commented Jul 9, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

rust-bors bot commented Jul 11, 2025

Uh oh!

rust-bors bot commented Jul 11, 2025

Uh oh!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

bors commented Jul 26, 2025

Uh oh!

This comment has been minimized.

bors commented Jul 26, 2025

Uh oh!

sebastianpoeplau commented Jul 28, 2025

Uh oh!

bjorn3 commented Jul 28, 2025

Uh oh!

bors commented Jul 28, 2025

Uh oh!

sebastianpoeplau commented Jul 28, 2025

Uh oh!

bors commented Jul 28, 2025

Uh oh!

This comment has been minimized.

bors commented Jul 28, 2025

Uh oh!

sebastianpoeplau commented Jul 29, 2025

Uh oh!

bors commented Jul 30, 2025

Uh oh!

bjorn3 commented Jul 31, 2025

Uh oh!

bjorn3 commented Jul 31, 2025

Uh oh!

sebastianpoeplau commented Aug 1, 2025

Uh oh!

sebastianpoeplau commented Aug 1, 2025

Uh oh!

Uh oh!

sebastianpoeplau commented Jul 9, 2025 •

edited

Loading